home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2864 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.0 KB
  1. Path: grafix.xs4all.nl!john.hendrikx
  2. Date: Mon, 05 Feb 96 21:35:01 GMT+1
  3. Newsgroups: comp.sys.amiga.programmer
  4. Distribution: world
  5. Subject: Re: Amiga doesn`t need Planar!
  6. MIME-Version: 1.0
  7. Content-Type: text/plain; charset=iso-8859-1
  8. Content-Transfer-Encoding: 8bit
  9. From: john.hendrikx@grafix.xs4all.nl (John Hendrikx)
  10. Message-ID: <john.hendrikx.4bur@grafix.xs4all.nl>
  11. Organization: Grafix Attack BBS Holland
  12.  
  13. In a message of 04 Feb 96 Michael Van Elst wrote to All:
  14.  
  15.  >> Because those are irrelevant, 8 bits per pixel is the standard, if planar
  16.  >> can't handle that fast than planar simply sucks.
  17.  
  18.  MVE> You mean because planar is not chunky and not suited for standard
  19.  MVE> microprocessors it sucks ? Why do you look for arguments then ?
  20.  
  21. I'm not, I'm just telling you how it is right now on most computer systems. 
  22. You however seem to defend planar thinking of stuff never even done before. 
  23. You actually are defending planar by thinking of a gfx-card which can address
  24. memory anyway it likes, and you make it sound like that this doesn't create any
  25. restrictions on the format of the gfx in memory.
  26.  
  27. BTW, is there a platform using Planar with 16 or more bitplanes, even 24
  28. bitplanes?  I believe there is a system which can do this...
  29.  
  30. I think the issue is much deeper however...  it is not just about Planar vs
  31. Chunky, it is about "Special Hardware" vs "General Purpose CPU('s)"
  32.  
  33.  >> Who's talking about the CPU?
  34.  
  35.  MVE> You are. If you do not use the CPU then your special hardware won't
  36.  MVE> have an advantage.
  37.  
  38. Sure it has, just the fact that Planar needs to go through all kinds of trouble
  39. to collect all bits in a single true-color pixel, and only then being able to
  40. perform a 'shade to 90% intensity' operation on it, then having to split those
  41. bits up again and store them tells me that there is much more involved to get a
  42. fast Planar display with 'cool' effects (ie, effects which the CPU and consoles
  43. are so damn good at).
  44.  
  45. Chunky hardware which operates on a rectangle can easily do stuff like shading
  46. that rectangle to a set intensity (if the data is TrueColor).  Or it can fill
  47. the rectangle with a specific color at each of the 4 edges and then do Phong or
  48. Gouraud shading.  The hardware could even do real time conversion from 24-bit
  49. TC to 16-bit TC to 8-bit CLUT.  These are operations which cannot be performed
  50. on single bitplanes at the time.  The hardware needs to work with the pixels as
  51. a whole.  Unlike scaling or rotation, which could have done without actually
  52. knowing what colors the pixels actually are (ie, you could rotate or scale 1
  53. bitplane at the time, so Planar can do this too).
  54.  
  55.  >> It would be kinda unfair to compare CPU Chunky vs Hardware Planar
  56.  >> (although even then Planar doesn't look too good).
  57.  
  58.  MVE> So you think it is fair to compare CPU Chunky vs. CPU Planar ?
  59.  
  60. Funny isn't it?:
  61.  
  62.  CPU Chunky vs CPU Planar           --> Planar looses big time
  63.  CPU Chunky vs Hardware Planar      --> About equally matched
  64.  Hardware Chunky vs Hardware Planar --> About equally matched (???)
  65.  
  66. Hey sure, a FAIR comparison might make Planar look just as good (that's why
  67. they call it fair).  The real world isn't fair however.
  68.  
  69.  >> easily handle the extra calculations needed 'in between' memory accesses
  70.  >> (like 040 C2P).
  71.  
  72.  MVE> As always you just think about Amiga hardware where the planar memory
  73.  MVE> system is 10 year old technology and the CPU is recent.
  74.  
  75. You forget however to mention that the 68040/25 isn't all that recent
  76. technology either.  A PPC604/133 would need extremely fast memory to get 0 ws
  77. on a cache miss, something like 5 ns memory.
  78.  
  79.  >> Anyway, I explained why I think wider memory busses wouldn't work as good
  80.  >> with Planar in an other message to you.
  81.  
  82.  MVE> And I explained why you can use the wider busses more flexible with
  83.  MVE> planar.
  84.  
  85. If what you claim is possible, ie, the ability to address the memory anyway you
  86. like, at any given time, then this would benefit Chunky just as much to give it
  87. 'planar' like abilities.
  88.  
  89. I'm not that good into these hardware issues however, but I think that this
  90. would be rather costly to add.  Also I have the feeling that this hasn't been
  91. done before which would imply that this is either a bad solution (in terms of
  92. production and design costs) or that the popular effects used in games and
  93. consoles this way are cheaper and easier to implement using Chunky based
  94. hardware.
  95.  
  96. You must realize that for all I care we use planar hardware which has the X and
  97. Y coordinate system swapped around, as long as the hardware is cheap and some
  98. combination of CPU/Hardware gets us the same speed and effects of the consoles
  99. (ie, the PSX for example).  Somehow I feel Planar doesn't cut it in this case,
  100. and that's why I rather see it replaced.  The main reason I think that it
  101. doesn't cut it is the amount of effects possible with the CPU... you can't put
  102. them ALL in hardware...
  103.  
  104. Grtz John
  105.  
  106. -----------------------------------------------------------------------
  107.  John.Hendrikx@grafix.xs4all.nl   TextDemo/FastView/Etc... development
  108. -----------------------------------------------------------------------
  109. -- Via Xenolink 1.981, XenolinkUUCP 1.1
  110.